Subject: John Pickens comments on HPR

From: "Ray Bird" <[email-masked]>
Date: Tue, 18 Jan 94 10:53:26 EST

John,
  Thanks for the corrections/comments on the HPR document.  Our
response to each comment is flagged by "*"s.  "Agree" means we
will fix the problem.

Ray
============================================================================
                      Subject:                              Time:  3:34 PM
  OFFICE MEMO         APPN HPR Feedback                     Date:  11/29/93
Here are a few comments on the HPR document draft dated
September 24, 1993.  I have more detailed feedback, but
figured it would be better to give at least this level of
feedback before the next draft went out.

I. Control point model

My strongest feedback regards the description of the APPN/HPR
control point vs. RTP layering.  It took me a while to finally
figure out that the actual implicit model was of the control
point logic of APPN/HPR being shared between old APPN sessions
and new HPR RTP sessions.  A reusable control point.  It would be
much cleaner to describe a set of common control point services
that could be used by other entities within the node, e.g. the
RTP/ANR route calculation entity.  A protocol boundary could
be defined within APPN/HPR (actually extensions to existing
protocol boundaries in the APPN architecture book, or a service
level interface see below).  Then, RTP could be characterized
as using this protocol boundary in pseudo code (ok, pseudo pseudo
code to simplify the writing).  As it is, APPN, HPR, Control Point,
RTP, ANR, are all muddled together.

(Also, I have said previously that it would be good to generalize
the notion of the APPN control point for usage by other node
services, such as DLS or other vendor defined functions.)

* The plan is to eventually provide intranode protocol boundaries
* for HPR components in an APPN node (hopefully sometime later this year).

II. RTP - SNA layering & Service Interface

My understanding previously was that RTP was essentially a
separable protocol stack, that, other than requiring access to
control point services for name registration and route calculation,
was separable from APPN.  RTP need not even run SNA.   However,
the writeup of RTP essentially is very intertwined with APPN/SNA.
A couple of suggestions here.

First, create a separate document for RTP.

Second,  create a service interface description for RTP.  (Actually
you need an architectural model, service interface, and protocol
description.)  What are its logical interface verbs.  connect(),
disconnect(), send(), receive(), and the verb parameters.  Also, perhaps
create a service interface for the control point functions used by RTP,
such as find-route(), ...  This formalism will force the separation of
layering such that RTP and APPN can be separately described (and
implemented).  It may also fix some inadvertant layering violations
that have crept into the architecture.

* The plan is to create a separate description for RTP and eventually
* provide its protocol boundaries with other APPN components within the
* node (as mentioned in the answer to question I).  However, it
* should be noted that IBM has no interest at this time in developing
* RTP to work with anything other than the APPN control point.

Third,  my understanding was that the fact that SNA BIND was carried
in an RTP connection activation was incidental.  The discussion in
7.2.2 implies that a BIND MUST be carried.  BIND is just data, right?
A BIND is only carried if the RTP user is communicating to an HPR
entity, right?  Modify the discussion to show a pure RTP connection
setup.  Then have a section under HPR that discusses what data is
placed into the RTP connection setup request by HPR.  Perhaps the
service interface approach could be used as an alternative documentation
method here also.

* Again, the separate RTP description will talk about the pure RTP
* connection setup.  The description on how APPN/HPR uses an RTP connection
* (distributed at the last AIW) will say that a BIND is carried as data
* along with the connection setup.

Finally, the performance graphs, proofs, design considerations etc.
are all interesting, but are out of place in the main body of a protocol
specification.  Maybe an informative appendix or separate white paper.

* Agree.  This type of information will be moved to an appendix.

III. Link Sharing

After scratching my head for a while it finally became apparent that
the data link was being shared by two logically independent protocol
stacks - APPN and HPR - duh.  Couple comments.

First, the mapping of FID2 and NLPs to a common link is not well
described at all.  A graphic or two is required showing what you
really mean.  It is confusing that FID2 uses a connection oriented
link scheme, and NLP uses connectionless, all on the same link.

Second, what are the rules for sharing the link?  For each NLP sent,
how many FID2 PIUs should be sent?  Does session priority influence
the relative traffic flows of each type?

Finally, the bullet in 4.1 beginning "FID2 PIUs and NLPs share link"
seems flawed.  How do you delineate the beginning and end of FID2
and NLP structures?  None of the example mappings use the first
3-4 bits to differentiate structure types anyway.

* Agree with all points.  More description and detail will be added
* to clarify this.

IV. Miscellaneous Comments

No particular order.

In a number of places there are imprecise handwaving implementation
guidelines.  For example section 7.2.4.5 session adaptive pacing.  Is
there any way to tighten up the specification, precise algorithms?
I'm concerned about how well the implementations will work with
this imprecision.

The whole discussion of limited resource links needs to be expanded
and clarified.
* The definition and operation of limited resource links in APPN is the same
* in HPR as in ISR except for deactivation.  Therefore, only the
* deactivation of limited resource links is described in the APPN/HPR
* document.  We will attempt to make this description better but
* it would be useful if you could give us some specifics.

Need to define subnet types, CNN, HPR, APPN, ....
* Agree.

3.1.5 - is the "minor modification for path switch" to base APPN
contained in this document?  Is enough information described to
enable an implementor to do it correctly?
* Yes.  The modification referred to here is calculating HPR only
* paths.  Will clarify what "minor modification" is.

6.3.2 - new SAP for NLP - are you dedicating a well known SAP
for this purpose?  SAPs are rare.  If it is a single SAP then it will
break multiple SAP implemetations, like SDLC-to-LLC2.  Are you
going to allow SNAP SAP?
* An IBM reserved value (X'C8') has been chosen for the default
* APPN/HPR SAP.  However, products may allow this value to be overriden
* (with any value chosen by a network administrator).
* A new well-known SAP has not been assigned.

7.2.3 - define dally, LMI, RASAPI, ...
* Agree.

7.2.4.1 and elsewhere - change all references to "customer" to
something else like "administrator".  Protocol specs are for engineers,
not sales folks.
* Agree

7.2.4.4.7 - "this is the current design direction" - Let's pin it down.
* Agree.

7.2.4.5 Session Adaptive Pacing - is it legal to have a concatenated
HPR-to-APPN-to-HPR configuration?  Also, need to specify more
precisely what it means for "window size to be immediately or
quickly be incremented".
* Yes it is legal to have any combination of ISR and HPR nodes
* along a session path.
* We will give some examples of incrementing the window size but
* the exact method used by the product will remain implementation
* dependent.

7.9 Session addressing - a graphic showing the layered/fan-out
relationship between SAD->TCID->NCE->Node would certainly be
helpful.
* We feel this is pretty well described but not all in one place.
* If we can find a suitable place to put such a description then
* we'll do it.

9.3 Connection Networks - this section needs to be rewritted for
clarification.  It is confusing.  Also would be helped with graphics.
* Connection Networks are used in APPN/HPR the same way they are used
* in APPN/ISR with the exception of ANR routing.  Much of section 9.3
* refreshes the reader's memory on how CNs works in APPN.  We will
* not provide a full description of CNs but will try to improve
* on what's already there.

9.6.2 and elsewhere -"architecture strongly recommends" - wrong
audience.  The "specification" recommends.
* Agree.

9.6.10 - Obtaining a New Path - conditions checked - indicate that
these are "AND" logic.  Also, it is not clear what you mean by
"subnet" (comment earlier made).
* Agree.

A.2.7 - TG Type  - what do each of the types actually mean?
* Recent changes to the format of the CV4680 have occurred such that
* the TG type field is no longer used to indicate HPR capability
* (these changes will be reflected in the next version of the document).

That's all for now...